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Abstract 


This document describes a general Data Validation and Certification 
Server (DVCS) and the protocols to be used when communicating with 
it. The Data Validation and Certification Server is a Trusted Third 
Party (TTP) that can be used as one component in building reliable 
non-repudiation services. 


Useful Data Validation and Certification Server responsibilities in a 
PKI are to assert the validity of signed documents, public key 
certificates, and the possession or existence of data. 


Assertions created by this protocol are called Data Validation 
Certificates (DVC). 


We give examples of how to use the Data Validation and Certification 
Server to extend the lifetime of a signature beyond key expiry or 
revocation and to query the Data Validation and Certification Server 
regarding the status of a public key certificate. The document 
includes a complete example of a time stamping transaction. 
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1. Introduction 


This document is the result of work that has been proposed and 
discussed within the IETF PKIX working group. The authors and some 
members of the group felt that promoting the rather new concepts into 
the standards process seemed premature. The concepts presented have 
been stable for some time and partially implemented. It was agreed 
that a publication as experimental RFC was an appropriate means to 
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get a stable reference document to permit other implementations to 
occur. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 
as shown) are to be interpreted as described in [RFC2119]. 


A Data Validation and Certification Server (DVCS) is a Trusted Third 
Party (TTP) providing data validation services, asserting correctness 
of digitally signed documents, validity of public key certificates, 
and possession or existence of data. 


As a result of the validation, a DVCS generates a Data Validation 
Certificate (DVC). The data validation certificate can be used for 
constructing evidence of non-repudiation relating to the validity and 
correctness of an entity’s claim to possess data, the validity and 
revocation status of an entity’s public key certificate and the 
validity and correctness of a digitally signed document. 


Services provided by a DVCS do not replace the usage of CRLs and OCSP 
for public key certificate revocation checking in large open 
environments, due to concerns about the scalability of the protocol. 


It should be rather used to support non-repudiation or to supplement 
more traditional services concerning paperless document environments. 
The presence of a data validation certificate supports 
non-repudiation by providing evidence that a digitally signed 
document or public key certificate was valid at the time indicated in 
the DVC. 


A DVC validating a public key certificate can for example be used 
even after the public key certificate expires and its revocation 
information is no longer or not easily available. Determining the 
validity of a DVC is assumed to be a simpler task, for example, if 
the population of DVCS is significantly smaller than the population 
of public key certificate owners. 


An important feature of the protocol is that DVCs can be validated by 
using the same protocol (not necessarily using the same service), and 
the validity of a signed document, in particular a DVC, can also be 
determined by means other than by verifying its signature(s), e.g., 
by comparing against an archive. 


The production of a data validation certificate in response to a 
signed request for validation of a signed document or public key 
certificate also provides evidence that due diligence was performed 
by the requester in validating a digital signature or public key 
certificate. 
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This document defines the use of digital signatures to insure the 
authenticity of documents and DVCs, and uses a corresponding 
terminology; the use of other methods to provide evidence for 
authenticity is not excluded, in particular it is possible to replace 
a SignedData security envelope by another one. 


2. Services provided by DVCS 


The current specification defines 4 types of validation and 
certification services: 


— Certification of Possession of Data (cpd), 

— Certification of Claim of Possession of Data (ccpd), 
— Validation of Digitally Signed Document (vsd), and 
— Validation of Public Key Certificates (vpkc). 


A DVCS MUST support at least a subset of these services. A DVCS may 
support a restricted vsd service allowing to validate data validation 
certificates. 


On completion of each service, the DVCS produces a data validation 
certificate — a signed document containing the validation results and 
trustworthy time information. 


2.1 Certification of Possession of Data 


The Certification of Possession of Data service provides evidence 
that the requester possessed data at the time indicated and that the 
actual data were presented to the Data Validation Server. 


2.2 Certification of Claim of Possession of Data 


The Certification of Claim of Possession of Data service is similar 
to the previous one, except that the requester does not present the 
data itself but a message digest. 


2.3 Validation of Digitally Signed Documents 


The Validation of Digitally Signed Document service is used when 
validity of a signed document is to be asserted. 


The DVCS verifies all signatures attached to the signed document 
using all appropriate status information and public key certificates. 
The DVCS verifies the mathematical correctness of all signatures 
attached to the document and also checks whether the signing entities 
can be trusted, for example by validating the full certification path 
from the signing entities to a trusted point (e.g., the DVCS's CA, or 
the root CA in a hierarchy). 
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The DVCS may be able to rely on relevant CRLs or may need to 
supplement this with access to more current status information from 
the CAs for example by accessing an OCSP service, a trusted directory 
service, or other DVCS services. 


The DVCS will perform verification of all signatures attached to the 
signed document. A failure of the verification of one of the 
signatures does not necessarily result in the failure of the entire 
validation, and vice versa, a global failure may occur if the 
document has an insufficient number of signatures. 


2.4 Validation of Public Key Certificates 


The Validation of Public Key Certificates service is used to verify 
and assert the validity (according to [RFC2459]) of one or more 
public key certificates at the specified time. 


When verifying a public key certificate, the DVCS verifies that the 
certificate included in the request is a valid certificate and 
determines its revocation status at a specified time. DVS checks the 
full certification path from the certificate’s issuer to a trusted 
point. Again, the DVCS MAY be able to rely on external information 
(CRL, OCSP, DVCS). 


3. Data Certification Server Usage and Scenarii. 


It is outside the scope of this document to completely describe 
different operational scenarii or usages for DVCS. 


See Appendix B and C for a set of some basic examples and use cases. 


The Validate Signed Document service can be used to support non- 
repudiation services, to allow use of the signed document beyond 
public key certificate revocation or expiry, or simply to delegate 
signature validation to a trusted central (company wide) service. 


The Validate Public Key Certificate service can be used when timely 
information regarding a certificate’s revocation status is required 
(e.g., high value funds transfer or the compromise of a highly 
sensitive key) or when evidence supporting non-repudiation is 
required. 


A data validation certificate may be used to simplify the validation 
of a signature beyond the expiry or subsequent revocation of the 
signing certificate: a Data validation certificate used as an 
authenticated attribute in a signature includes an additional 
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assertion about the usability of a certificate that was used for 
signing. In order to validate such a signature it may be sufficient 
to only validate the data validation certificate. 


A DVCS may include additional key exchange certificates in a data 
validation certificate to validate a key exchange certificate in 
order to provide to an application a set of additional authorised 
recipients for which a session key should also be encrypted. This 
can be used for example to provide central management of a company 
wide recovery scheme. Note, that the additional certificates may not 
only depend on the requested certificate, but also on the requester’s 
identity. 


The Certification of Claim of Possession of Data service is also 
known as time stamping. 


The Certification of Possession of Data service can be used to assert 
legal deposit of documents, or to implement archival services as a 
trusted third party service. 


The Data Validation and Certification Server Protocols can be used in 
different service contexts. Examples include company-wide 
centralised services (verification of signatures, certification of 
company certificates), services to cooperate in a multi-organization 
community, or general third party services for time stamping or data 
archival. 


An important application of DVCS is an enterprise environment where 
all security decisions are based on company wide rules. A company 
wide DVCS service can be used to delegate all technical decisions 
(e.g., path validation, trust configuration) to a centrally managed 
service. 


In all cases, the trust that PKI entities have in the Data Validation 
and Certification Server is transferred to the contents of the Data 
Validation Certificate (just as trust in a CA is transferred to the 
public key certificates that it issues). 


A DVCS service may be combined with or use archiving and logging 
systems, in order to serve as a strong building block in non- 
repudiation services. In this sense it can be regarded as an 
Evidence Recording Authority [ISO-NR]. 
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4. Functional Requirements for DVCS 
The DVCS MUST 


1. provide a signed response in the form of a data validation 
certificate to the requester, as defined by policy, or an error 
response. The DVCS service definition and the policy define how 
much information that has been used by the DVCS to generate the 
response will be included in a data validation certificate, e.g., 
public key certificates, CRLs, and responses from other OCSP 
servers, DVCS, or others. 


2. indicate in the data validation certificate whether or not the 
signed document, the public key certificate(s), or the data were 
validated, and, if not, the reason why the verification failed. 


3. include a strictly monotonically increasing serial number in each 
data validation certificate. 


4. include a time of day value or a time stamp token into each data 
validation certificate. 


5. sign each data certification token using a key that has been 
certified with a dvcs signing extended key purpose, and include a 
reference to this certificate as a signed attribute in the 
signature. 


6. check the validity of its own signing key and certificate before 
delivering data validation certificates and MUST not deliver data 
validation certificate in case of failure. 


A DVCS SHOULD include within each data validation certificate a 
policy identifier to determine the trust and validation policy used 
for DVC's signature. 


5. Data Certification Server Transactions 


A DVCS transaction begins with a client preparing a Data Validation 
and Certification Request. The request always contains data for 
which validity, correctness or possession is to be certified. 


The request MAY be encapsulated using a security envelope to provide 
for authentication of both requester and server. Requester 
authentication can be achieved by several of the formats described in 
CMS, in particular, signedData. 
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The DVCS client chooses an appropriate transport mechanism to convey 
the requests to a DVCS. It may also be necessary to choose a 
transport mechanism providing confidentiality and, in particular, 
allowing authentication of the DVCS by the requestor, e.g., TLS or 
CMS or S/MIME encryption. 


If the request is valid, the DVCS performs all necessary 
verifications steps, and generates a Data Validation Certificate 
(DVC), and sends a response message containing the DVC back to the 
requestor. 


The Data Validation Certificate is formed as a signed document (CMS 
SignedData). 


As with the request, it may be necessary to choose a transport 
mechanism that provides for confidentiality to carry the DVC. DVCs 
are not necessarily transported the same way as requests, e.g., they 
can be returned using e-mail after an online request received via 
HTTPS. 


If the request was invalid, the DVCS generates a response message 
containing an appropriate error notification. 


Upon receiving the response, the requesting entity SHOULD verify its 
validitv, i.e., whether it contains an acceptable time, the correct 
name for the DVCS, the correct request information and message 
imprint, a valid signature, and satisfactory status, service and 
policy fields. 


When verifying the validity of a DVC, it is up to the requestor's 
application to check whether a DVCS's signing certificate is valid. 
Depending on the usage environment, different methods, online or out 
of band, e.g., CRLs, DVCS, or OCSP, may have to be used. 


After all checks have passed, the data validation certificate can be 


used to authenticate the correctness or possession of the 
corresponding data. 


A DVCS may return more than one DVC corresponding to one request. In 
this case, all but one request have a global status of 'WAITING'. 


6. Identification of the DVCS 


In order to be able to import elements from dvcs the following object 
identifier is used as a ASN.1 module identifier. 


id-mod-dvcs OBJECT IDENTIFIER ::- (iso(l) identified-organization (3) 
dod(6) internet (1) security(5) mechanisms(5) pkix(7) id-mod(0) 15) 
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The DVCS that use SignedData to provide authentication for DVCs MUST 
sign all data certification messages with a key whose corresponding 
certificate MUST contain the extended key usage field extension as 
defined in [RFC2459] Section 4.2.1.14 with KeyPurposelD having value 
id-kp-dvcs. This extension MUST be marked as critical. 


The Data Validation Certificate MUST contain an ESSCertID 
authenticated attribute for the certificate used by the DVCS for 
signing. 


id-kp-dvcs OBJECT IDENTIFIER ::- (iso(l) identified-organization (3) 
dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 10} 


Consistent KeyUsage bits: 
digitalSignature, nonRepudiation, keyCertSign, cRLSign 


A DVCS’s certificate MAY contain an Authority Information Access 
extension [RFC2459] in order to convey the method of contacting the 
DVCS. The accessMethod field in this extension MUST contain the OID 
id-ad-dvcs: 


id-ad-dvcs OBJECT IDENTIFIER ::- {iso(1) identified-organization (3) 
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ad(48) 4} 


The value of the 'accessLocation' field defines the transport (e.g., 
an URI) used to access the DVCS. 


7. Common Data Types 


There are several common data types that occur in the request and the 
response data structures. These data types are either defined by 
this document or imported from other sources. This chapter defines 
and describes these types and lists their usages. 


7.1 Version: 


The request and the response include an optional integer field 
Specifying the version of the data structure. For both fields the 
value is 1, or the field is not present at all in this version of the 
protocol. 
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7.2 Digestinfo: 


This element is defined in [RFC2315]. Since the status of that 
document is informational, the definition is repeated here: 


DigestInfo ::= SEQUENCE { 
digestAlgorithm DigestAlgorithmIdentifier, 
digest Digest ) 

Digest ::- OCTET STRING 


The fields of type DigestInfo have the following meanings: 


- The field 'digestAlgorithm' identifies the message-digest algorithm 
(and any associated parameters) under which data are digested. 


- The field 'digest' is the result of the message-digesting process. 

A DigestInfo is used in two places: 

— as a data portion for the ccpd service, and 

— in all a data validation certificates to hold a digest of the data 
portion of the corresponding request or a copy of the data field 
for a ccpd service. 

7.3. Time Values 
Indicators of time can be present in requests and responses. In the 
most simple form, the time is represented as GeneralizedTime where 


fractions of seconds are allowed. 


An alternate form is a timeStampToken from a TSA, or as a DVC (or 
some other token) from another third party service. 


It is a matter of policy whether a DVCS tries to interpret or 
validate a Time Value in a request. 


DVCSTime ::- CHOICE { 
genTime GeneralizedTime, 
timeStampToken ContentInfo ] 


Future versions of the protocol MAY include additional time formats. 


Time values generated by the DVCS are increasing but not necessarily 
unique, an order among DVCs is defined by serial numbers. 
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7.4. PKIStatusInfo 


This structure is defined in [RFC2510]. It is used as component of 
the 'chain' field of a TargetEtcChain structure, and as a global 
status indicator in the DVCSResponse structure. Every occurrence of 
PKIStatusInfo is generated by the responding DVCS to reflect the 
result of some local verification. 


7.5. TargetEtcChain 


A TargetEtcChain structure contains certificates and other indicators 
to describe either (in a request for a cpkc service) information to 
be validated, or the result of the verifications. The structure may 
also contain information about policies and policy mappings. 


The details about how to fill in and to interpret the structure are 
defined later for each service. 


The 'pathProcInput' field contains information about policies and 
policy mapping to be used or used during a validation. 


In a response, the 'pkistatus' and 'certstatus' choices can only 
occur in the 'chain' sequence. If present, they contain the result 
of a local verification of the immediately preceding element, or of 
the target value, if it is the first element in the 'chain' sequence. 
If no 'pkistatus' or 'certstatus' is present, the DVCS considers all 
elements in the 'chain' as trustworthy. Note, that there may be a 
valid OCSP response or DVC indicating an invalid certificate. 


TargetEtcChain ::= SEQUENCE ( 
target CertEtcToken, 
Chain SEQUENCE SIZE (1..MAX) OF 
CertEtcToken OPTIONAL, 
pathProcInput [0] PathProcInput OPTIONAL l) 
PathProcInput ::= SEQUENCE { 
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF 
PolicyInformation, 
inhibitPolicyMapping BOOLEAN DEFAULT FALSE, 
explicitPolicyReqd BOOLEAN DEFAULT FALSE } 
CertEtcToken ::= CHOICE { 
certificate [0] IMPLICIT Certificate , 
esscertid [1] ESSCertId , 
pkistatus [2] IMPLICIT PKIStatusInfo , 
assertion [3] ContentInfo , 
crl [4] IMPLICIT Certificatelist, 
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ocspcertstatus [5] IMPLICIT CertStatus, 
oscpcertid [6] IMPLICIT Certld , 
oscpresponse [7] IMPLICIT OCSPResponse, 
capabilities [8] SMIMECapabilities, 
extension Extension } 


Certificate, PolicyInformation and CertificateList are defined in 
[RFC2459]. ESSCertId is defined in [RFC2634]. CertId, OCSPResponse 
and CertStatus are defined in [RFC2560]. PKIStatusField is defined 
in [RFC2510]. 


The choice 'assertion” can contain a data validation certificate, or 
a timeStamp, or other assertions. 


The choices 'assertion', 'ocspresponse' and 'crl' are provided by 


services external to the responding DVCS. The choices 'certStatus' 
and 'pkistatus' reflect decisions made directly by the responding 
DVCS. 


As a replacement for certificates, certification identifiers 
(ESSCertId, CertId) MAY be used in requests and responses, if this 
is sufficient to perform the service, e.g., when the corresponding 
certificates are provided elsewhere in a request or response (as part 
of the SignedData type). 


Certificate or certification identifiers of certification authorities 
MAY occur in any order and MAY represent several certification 
chains. 


The choice 'capabilities' can be used to indicate SMIMECapabilities. 
It applies to the certificate identified by the preceding element in 
the sequence. 


7.6. DVCSRequestInformation 


A DVCSRequestInformation data structure contains general information 
about the Data Validation and Certification Request. This structure 
occurs in a request, and is also included in a corresponding Data 
Validation Certificate. 


DVCSRequestInformation ::= SEQUENCE { 
version INTEGER DEFAULT 1 , 
service ServiceType, 
nonce INTEGER OPTIONAL, 
requestTime DVCSTime OPTIONAL, 
requester [0] GeneralNames OPTIONAL, 
requestPolicy [1] PolicyInformation OPTIONAL, 
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dvcs [2] GeneralNames OPTIONAL, 
dataLocations [3] GeneralNames OPTIONAL, 
extensions [4] IMPLICIT Extensions OPTIONAL 


} 


The ServiceType type enumerates the DVCS service type of a request. 
See chapter 2 for the description of the services. 


ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) } 
7.7. GeneralName and GeneralNames 


There are several occurrences of SEQUENCES of GeneralName and 
GeneralNames. These structures are imported from [RFC2459]. 


8. Data Validation and Certification Requests 


A Data Validation and Certification request is a ContentInfo defined 
in [RFC2630]. 


It may consist of a [RFC2630] content with a contenttype id-ct- 
DVCSRequestData signalling a DVCSRequestData, 


id-ct-DVCSRequestData OBJECT IDENTIFIER ::= (iso(1) member-body (2) 
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) ct (1) 7} 


These data are optionally encapsulated by contenttypes that provide 
for authentication and/or confidentiality. 


This document describes the usage of a SignedData construct of 
[RFC2630] where the contenttype indicated in the eContentType of the 
encapContentInfo is id-ct-DVCSRequestData and the eContent of the 
encapContentInfo, carried as an octet string, contains a 
DVCSRequestData structure. 


When using a SignedData structure, a Data Validation and 
Certification Request MAY contain several SignerInfo structures, and 
countersignature attributes depending on operational environments. 
When an end user client creates the request, there is one or zero 
SignerInfo. A relaying DVCS MAY add an additional signature or a 
countersignature attribute, or MAY use another encapsulation from 
IRFC2630) that provides for authentication and/or confidentiality. 


The content of a request consists of a description of the desired 
service and additional parameters, the data to be validated, and an 
optional identifier of the request. 
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DVCSRequest ::= SEQUENCE { 
requestInformation DVCSRequestInformation, 
data Data, 
transactionIdentifier GeneralName OPTIONAL 


} 
The ’DVCSRequest.requestInformation’ element contains general 
information about the request. It is filled in by the requester as 


follows: 


— The ‘version’ field is set to 1 or the field is absent in this 
version of the protocol. 


The field 'service' contains the requested service. 


— The 'nonce” field MAY be used to provide additional protection 
against replay or content guessing attacks. 


- The ’requestTime’ field MAY be used to indicate the time for which 
the requested service should be performed. For a vsd and cpkc 
service, it specifies the time for which the validity of a signed 
document or certicates is to be asserted. For the other service, 
the field is ignored by the DVCS. If the field is absent, the 
current time is assumed. 


— The value of the 'requester” field indicates the requesting entity. 


The interpretation and usage of this field MUST be defined by the 
DVCS policy. 


Some usage examples are: 


If the field is present, and the request is signed, a DVCS MAY 
require that the field MUST match the identity (subjectName or 
subjectAltName extension) of the corresponding signature 
certificate. 


A request MAY be signed by a DVCS when relaying it to another DVCS. 


When acting as a relay, a DVCS MAY add its own identity in the 
request relayed to another service provider, and it MAY remove the 
initial value. 


- The ’requestPolicy’ field SHOULD indicate the policy under which 
the validation is requested. This field MUST be checked by the 
DVCS to verify agreement with its own policy. The absence of this 
field indicates that any policy is acceptable. 
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— The 'dves' field MAY be used to indicate a list of DVCS which can 


be contacted to provide (additional) information or to perform 
additional operations necessary to produce the response. 


It is up to the DVCS policy whether to honor this field or not, and 
to define which choice of a general name is acceptable (e.g., an 
URL or a DN). 


The 'dataLocations' field MAY be used to indicate where a copy of 
the 'data' field of the request or supplementary information can be 
obtained. The DVCS does not use this field for its own operation, 
the exact interpretation of this field is defined by applications. 


The 'requestTime' field MAY be used to indicate the time for which 
the requested service should be performed. For a vsd and cpkc 
service, it specifies the time for which the validity of a signed 
document or certicates is to be asserted. For the other service, 
the field is ignored by the DVCS. If the field is absent, the 
current time is assumed. The DVCS service may have a time limit or 
a delta time limit regarding current time which are specified in 
the local policy of the DVCS service. 


The “extensions” field MAY be used to include additional 
information. Extensions may be marked critical or not in order to 
indicate whether the DVCS is supposed to understand them. This 
document does not define extensions. 


The DVCSRequest.data contains service-specific content, defined by 
each particular service provided by the DVCS. 


Depending on the requested service type, the field may contain a 
signed document, a list of certificates, a message digest or 
arbitrary data. 


The following type is used: 


Data ::= CHOICE ( 
message OCTET STRING , 
messagelmprint DigestInfo, 
certs SEQUENCE SIZE (1..MAX) OF 


} 


TargetEtcChain 


The requester fills the 'data' element as follows: 


— For a vsd service request, the requestor encapsulates a CMS 


SignedData object in the value octets of the 'message” choice. 
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It is up to the requester to decide whether and how to provide any 
certificate that may be needed to verify the signature(s) in the 
signedData object. A requester MAY add certificates to the 
encapsulated signedData object or in the certificate list of the 
request. 


— For a cpkc service request the 'certs' choice is used. 


Each certificate to be verified MUST be included in a separate 
instance of TargetEtcChain. The 'TargetEtcChain.chain' field, if 
present, indicates one or more chains of trust that can be used to 
validate the certificate. The DVCS MAY choose to select a subset 
of certificates as certification path, or to ignore this field. 

The 'TargetEtcChain.pathProcInput' field, if present, indicates the 
acceptable policy set and initial settings for explicit-policy- 
indicator and inhibit-policy-mapping indicators to be used in X.509 
public key certificate path validation (see [RFC2459]). 


Only the Certificate, ESSCertId, CertId or Extension choices of the 
TargetEtcChain can be used in the request. 


The requester is responsible for providing sufficient information 
to the DVCS to identify the corresponding certificates. 


- For a ccpd service the 'messageImprint' choice is used. 


The hash algorithm indicated in the hashAlgorithm field SHOULD be a 
"strong" hash algorithm (that is, it SHOULD be one-way and 
collision resistant). It is up to the Data Certification Server to 
decide whether or not the given hash algorithm is sufficiently 
"strong" (based on the current state of knowledge in cryptanalysis 
and the current state of the art in computational resources, for 
example). 


- For a cpd service the 'message' choice is used. 
The field contains requester-specific data with any type of 


content. The DVCS does not inspect, modify, or take any particular 
action based on the particular content of the 'message' field. 


The field ’DVCSRequest.transactionIdentifier’ MAY be used in order to 
associate DVCS responses containing error messages, to requests. For 
example, in a mail based environment, the parameter could be a copy 
of a messageid. Note, that the transactionIdentifier is not 
necessary for associating a request with a valid data validation 
certificate. 
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9. DVCS Responses 


This chapters describes the data structures that are created by a 
DVCS to indicate the results of validation and certification 
requests. 


A DVCS Response structure is generated by the DVCS as a result of 
processing of the data validation and certification request. 


A Data Validation response contains an [RFC2630] ContentInfo with a 
type of id-ct-DVCSResponseData signalling a DVCSResponse structure. 


id-ct-DVCSResponseData OBJECT IDENTIFIER ::= ( iso(l) member-body (2) 
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) ct (1) 8 ) 


The data MAY be encapsulated by constructs of [RFC2630] in order to 
provide authentication of the DVCS, and or integrity and 
confidentiality of the request. This document specifies the usage of 
a SignedData construct of [RFC2630]. 


The contenttype indicated in the eContentType of the encapContentInfo 
is of type id-ct-DVCSResponseData, signalling a DVCSResponse as 
eContent of the encapContentInfo (carried as an octet string). The 
DVCS SHOULD use a key for which a corresponding certificate indicates 
in an extendedKeyUsage the purpose of DVCS signing. 


In a critical situation when a DVCS cannot produce a valid signature 
(if the DVCS's signing key is known to be compromised, for example), 
the DVCSResponse, containing the error notification, MUST be 
generated as a signedData with no signerInfo attached. Receiving 
unsigned DVCSResponse MUST be treated by the clients as a critical 
and fatal error, and the content of the message should not be 
implicitly trusted. 


A valid response can contain one of the following: 


1. A Data Validation Certificate (DVC), delivering the results of 
data validation operations, performed by the DVCS. 


2. An error notification. This may happen when a request fails due 
to a parsing error, requester authentication failure, or anything 
else that prevented the DVCS from executing the request. 
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The following type is used: 


DVCSResponse ::= CHOICE { 
dvCertInfo DVCSCertInfo , 
dvErrorNote [0] DVCSErrorNotice ) 


9.1. Data Validation Certificate 


A Data Validation Certificate is a signedData object containing a 
DVCSResponse with a 'dvCertInfo' choice. 


DVCSCertInfo::- SEQUENCE { 

version Integer DEFAULT 1 , 

dvReqInfo DVCSRequestInformation, 

messagelmprint DigestInfo, 

serialNumber Integer, 

responseTime DVCSTime, 

dvStatus [0] PKIStatusInfo OPTIONAL, 

policy [1] PolicyInformation OPTIONAL, 

reqSignature [2] SignerInfos OPTIONAL, 

certs [3] SEQUENCE SIZE (1..MAX) OF 
TargetEtcChain OPTIONAL, 

extensions Extensions OPTIONAL } 


The DVCSCertInfo structure is returned as a result of successful 
execution of data validation service. It contains the results of the 
data validation, a reference to the original request, and other 
parameters. Please note that 'successful execution” does not 
necessarily mean that the validation itself was successful - a 
DVCSCertInfo may contain both the 'valid' and 'invalid' results. 


The DVCS creates a DVCSCertInfo as follows: 


- The 'version' field is never present in this version of the 
protocol. 


The 'dvReqInfo' is essentially a copy of the ’requestInformation’ 
field of the corresponding request. The DVCS MAY modify the fields 
'dvcs', 'requester', 'dataLocations', and 'nonce' of the ReqInfo 
structure, e.g., if the request was processed by a chain of DVCS, 
if the request needs to indicate DVCS, or to indicate where to find 
a copy of the data from a 'vpd' request. The only modification 
allowed to a 'nonce' is the inclusion of a new field if it was not 
present, or to concatenate other data to the end (right) of an 
existing value. 
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— The 'DVCSCertInfo.messagelmprint' field is computed from the 'data' 
field of the corresponding request as follows: 


For the 'certs' choice (the 'vpkc' service), the digest is computed 
over the DER encoded data value. For a 'message' choice (the 'vsd' 
and the 'vpd' services) the digest is computed over the value 
octets (not including tag and length octets) of the OCTET STRING. 
It is up to the DVCS to choose an appropriate digest algorithm. 


For a 'messageImprint' choice (the 'vcpd' service), the 
'messagelmprint' of the DVCSRequest is copied as is. 


- The 'DVCSCertInfo.serialNumber' field contains a unique identifier 
of the request. 


- The field 'responseTime' indicates a time value associated with the 
response. The value MAY be a locally generated one, or a signed 
TimeStampToken (TST) or DVC obtained from an external service. 
Before using a value obtained from an external service, the DVCS 
must validate it according the rules of the external service. 


— The field 'DVCSCertInfo.dvStatus' reflects a collective result of 
the validation. 


If the field is missing, it is an equivalent of the SUCCESS 
status. 


For a vkpc, if the status field is present and set to SUCCESS, it 
indicates that all certificates were successfully validated. If it 
is present and set to FAILED, it indicates that all or some of the 
certificates failed validation, and the specific status of the 
'certs' should be investigated, at least one of the elements of the 
'certs' TargetEtcChain structures MUST have a failure status. 


If the field 'dvStatus' does not indicate success ('granted' or 
'granted with mods') the element 'faillnfo' MAY indicate the reason 
for the failure. Note that the field 'certs' MAY contain 
additional information about verification failures. 


A failure of the verification of one of the signatures does not 
necessarily result in failing to validate a signed document. For 
example, as long as a sufficient number of signature was 
successfully verified, a DVC with status 'grantedWithMods' may be 
produced. A DVC with status 'granted' MUST only be produced if all 
signatures verified successfully. 


Adams, et al. Experimental [Page 19] 


RFC 3029 DVCS Protocols February 2001 


The field MUST be present, and the status must be set to WAITING, 
if no final response can be immediately available. It is assumed 
that the DVCS provides an additional final status some time later. 
The details of the necessary procedures are part of the DVCS 
policy. 


In case of failure, the requester can further investigate the cause 
of the failure, by looking into the TargetEtcChain fields. 
'CertEtctoken.pkistatus' fields will indicate which item(s) has 
failed or succeeded the validation and for what reason. 


- The 'DVCSCertInfo.policy' field indicates the policy under which 
the DVCS operates. 


- If present, 'DVCSCertInfo.reqSignature' MUST be the same value as 
the signerInfos field of the corresponding request. It is a policy 
decision whether to include this field. 


— The 'DVCSCertInfo.certs' field contains the results of the 
verifications made by the DVCS. For the cpkc service, each element 
contains a copy of a corresponding field of the request with the 
selected subset in the targetAndChain subfield and the results of 
the verifications, and additional certificates or certificate 
references, e.g., from certification authorities or as described in 


appendix C.3. For a vsd service, each element contains the result 
of the validation of one signature of the signed document to be 
validated. 


In case of a global status of WAITING, the DVCS MAY choose to 
return an individual status of waiting in some of the 'certs' 
field, or not to return such a TargetEtcChain at all. 


The 'acceptablePolicySet' sequence indicates the policies and 
mappings that were processed during X.509 public key certificate 
path validation.  PolicyMappingsSyntax is defined in [RFC2459]. 


— The 'extensions' field MAY be used to return additional information 
to the client. Extensions MAY be marked critical or not in order 
to indicate whether the client MUST understand them. This document 
does not define extensions. 
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9.2. DVCS Error Notification 


A DVCS Error Notification is a CMS signedData object containing a 
DVCSResponse with a 'dvErrorNote' choice. 


DVCSErrorNotice ::= SEQUENCE ( 
transactionStatus PKIStatusInfo , 
transactionIdentifier GeneralName OPTIONAL ) 

The PKIStatusInfo is defined in [RFC2511]. For the purposes of 


communicating the DVCSErrorNotice, the following subset of 
PKIFailureInfo values is used: 


PKIFailureInfo ::= BITSTRING ( 
badRequest (2), 
-- transaction not permitted or supported 
badTime (3), 


-- messageTime was not sufficiently close to the system time, 
-- as defined by local policy 


badDataFormat (5), 
-- the data submitted has the wrong format 
wrongAuthority (6), 


-- the DVCS indicated in the request is different from the 
-- one creating the response token 

incorrectData (7) 

--the requester's data (i.e., signature) is incorrect ) 


In the DVCSErrorNotice, the PKIStatus field of the PKIStatusInfo must 
be set to REJECTED. 


The 'statusString' field of PKIStatusInfo can be used to accommodate 
extra text, such as a reason for the failure, for example "I have 
gone out of service". The DVCS initializes the 
'DVCSErrorNotice.transactionIdentifier' with a copy of the 
'DVCSRequest.transactionIdentifier' field of the corresponding 
request. 


In certain circumstances, a DVCS may not be able to produce a valid 
response to a request (for example, if it is unable to compute 
Signatures for a period of time). In these situations the DVCS MAY 
create a response with an DVCSErrorNotice but no signature. 


DVCS clients SHOULD NOT trust unsigned responses. A DVCS client MAY 
trust unsigned responses, if the communication channel provides for 
server authentication (e.g., by services defined by TLS [RFC2246]). 
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10. 


10. 


10 


Transports 


There is no mandatory transport mechanism in this document. All 

mechanisms are optional. Two examples of transport protocols are 
given which allow online exchange of request and a response, and 

asynchronous communication between a client and a DVCS. 


A DVCS MAY use a combination of protocols, for example in order to 
return additional DVCs. 


1 DVCS Protocol via HTTP or HTTPS 


This subsection specifies a means for conveying ASN.l-encoded 
messages for the DVCS protocol exchanges via the HyperText Transfer 
Protocol. 


The DER encoded DVCS requests and responses are encapsulated using a 
simple MIME object with Content-Type application/dvcs (and with the 
default binary encoding). 


This MIME object can be sent and received using common HTTP or HTTPS 
processing engines over WWW links and provides a simple client-server 
transport for DVCS messages. 


.2 DVCS Protocol Using Email 


This section specifies a means for conveying ASN.l-encoded messages 
for the protocol exchanges described in Section 8 via Internet mail. 


The DER encoded DVCS requests and responses are encapsulated using a 
simple MIME object with Content-Type application/dvcs with an 
appropriate Content-Transfer-Encoding. 


This MIME object can be sent and received using MIME processing 
engines and provides a simple Internet mail transport for DVCS 
messages. 


In order to be able to associate a possible error response with a 
request, the requester SHOULD use the field 'transactionIdentifier'. 
The requester SHOULD not make any assumption about the usage of 
message header fields by the responding service, in particular the 
usage of fields like Subject, Message-ID or References. 
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11. Security Considerations 
This entire chapter discusses security considerations. 


When designing a data validation and certification service, the 
following considerations have been identified that have an impact 
upon the validity or "trust" in the data validation certificate. 


It is imperative that keys used to sign DVCs are guarded with proper 
security and controls in order to minimize the possibility of 
compromise. Nevertheless, in case the private key does become 
compromised, an audit trail of all the DVC generated by the DVCS 
SHOULD be kept as a means to help discriminate between genuine and 
false DVCs. A DVCS MAY provide for a vsd service to validate DVCs 
created by this DVCS or another one solely based on the audit trail. 


When confidentiality and server authentication is required, requests 
and responses MAY be protected using appropriate mechanisms (e.g., 
CMS encapsulation [RFC 2630] or TLS [RFC2246]). 


Server authentication is highly recommended for the vsd and cpd 
service. 


Client identification and authentication MAY use services defined by 
TLS [RFC2246]) instead of, or in addition to, using a CMS format 
providing authentication. 


12. Patent Information 


The following United States Patents related to data validation and 
certification services, listed in chronological order, are known by 
the authors to exist at this time. This may not be an exhaustive 
list. Other patents may exist or be issued at any time. 

Implementers of the DVCS protocol and applications using the protocol 
SHOULD perform their own patent search and determine whether or not 
any encumberences exist on their implementation. 


# 4,309,569 Method of Providing Digital Signatures 
(issued) January 5, 1982 

(inventor) Ralph C. Merkle 

(assignee) The Board of Trustees of the Leland Stanford Junior 
University 


# 5,001,752 Public/Key Date-Time Notary Facility 
(issued) March 19, 1991 
(inventor) Addison M. Fischer 
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# 5,022,080 Electronic Notary 
(issued) June 4, 1991 
(inventors) Robert T. Durst, Kevin D. Hunter 


4 5,136, 643 Public/Key Date-Time Notary Facility 
(issued) August 4, 1992 

(inventor) Addison M. Fischer 

(Note: This is a continuation of patent # 5,001,752.) 


# 5,136,646 Digital Document Time-Stamping with Catenate Certificate 
(issued) August 4, 1992 

(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 

( 


assignee) Bell Communications Research, Inc., 


# 5,136,647 Method for Secure Time-Stamping of Digital Documents 
(issued) August 4, 1992 

(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 

( 


assignee) Bell Communications Research, Inc., 


# 5,373,561 Method of Extending the Validity of a Cryptographic 
Certificate 

(issued) December 13, 1994 

(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 

(assignee) Bell Communications Research, Inc., 


# 5,422,95 Personal Date/Time Notary Device 
(issued) June 6, 1995 
(inventor) Addison M. Fischer 


# 5,781,629 Digital Document Authentication System 
(issued) July 14, 1998 

(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr. 
(assignee) Surety Technologies, Inc., 
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APPENDIX A — PKCS #9 Attribute 


We define a PKCS #9 [PKCS9] attribute type. The attribute type has 
ASN.1 type SignedData and contains a data validation certificate. 


The object identifier id-aa-dvcs-dvc identifies the data validation 
certificate attribute type. 


id-aa-dvcs-dvc OBJECT IDENTIFIER ::= (iso(1) member-body (2) 
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 29} 


The attribute may be used as an authenticated or unauthenticated 
attribute in CMS SignedData documents. 


APPENDIX B - Signed document validation. 


We present some examples of a possible use of DVCS in the context of 
validation of signed documents. 


B.1 Signed document validation 


The example covers the case where a DVCS is used by a signer to 
obtain a proof that a document's structure, including one or more 
attached signatures, is/was correct, after the document was signed. 


The DVC can be produced either by a DVCS that is trusted by the 
Signer, or by a DVCS that is trusted by an intended verifier of the 
document. 


The signer uses the obtained DVC as an evidence that its intentions 
were good and it produced a signed document using the 
environment (keys, algorithms, etc) that was known to be OK. 


It produces a stand-alone document that can be used to extend the 
life of a signature. This example assumes that we have total trust 
in the Data Validation and Certification Server. 


Signature algorithms and keys have a finite lifetime. Therefore, 
Signatures have a finite lifetime. The Data Certification Server can 
be used to extend the lifetime of a signature. 


In order to extend the lifetime of a signature in this way, the 
following technique can be used: 


1) The signature needs to be certified: 


The signed message is presented to the Data Validation and 
Certification Server in a 'vsd' service request. 
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The DVCS verifies that the signature and certificates are valid at 
that time by checking expiry dates, status information, or DVCs, 
and returns a DVC. 


2) The DVC SHOULD be verified. 


The signature of the Data Validation and Certification Server in 
data certification token SHALL be verified using the Data 
Certification Server's valid verification key. 


A signer's signing key (and therefore, its signature) is only valid 
until some specified time T1. The DVCS’s signing key (and therefore, 
its signature) is valid until some specified time T2 that is 
(usually) after time T1. Without certification, the signer's 
signature would only be valid until time Tl. With certification, the 
signer’s signature remains valid until time T2, regardless of 
subsequent revocation or expiry at time Tl. 


If the signature of the DVCS is valid, the trust we have in the DVCS 
allows us to conclude that the original signature on the data was 
valid at the time included in the DVC. 


The DVCS signing key MUST be of a sufficient length to allow fora 
sufficiently long lifetime. Even if this is done, the key will have 
a finite lifetime. Since data validation certificates are just 
another type of signed documents, they can be validated using 
(another) DVCS. 


APPENDIX C — Verifying the Status of a Public Key Certificate 
We now present three examples of how to produce a data validation 
certificate that can be used to assert that a public key certificate 
is valid, trusted, and can be used for a particular purpose. 
A client wants to use a given public key certificate either to use it 
to verify a signature on a document or to use it for document 
encryption. 
A DVCS MUST have access to current information regarding public 
certificate status, it can therefore be used to verify the revocation 
status of a certificate at the current time. 
The following technique can be used: 


A) The public key certificate needs to be validated. 


The certificate is presented to the Data Certification Server 
using a 'vpkc' service. 
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C) 


The Data Validation and Certification Server verifies that the 
public key certificate is valid and that it hasn't been revoked 
and then returns a data validation certificate. 


The data validation certificate MUST be verified. 
The signature of the Data Certification Server in the data 
certification token SHALL be verified using the Data Validation 


and Certification Server’s valid certificate. 


The public key certificate is used: 


C.1) A clients's own public key certificate (i.e., the corresponding 


private key) can be used to add a signature to a document. The 
signing certificate and the data validation certificate can be 
added as signed attributes to the signature. 


A data validation certificate can now be used during the 
validation signatures using the key contained in the public key 
certificate. This service provided by the DVCS can be thought 
of as a supplement to the usual method of checking revocation 
status. 


In other words, signature validation at a later time does not 
necessarily require access to the revocation status of the 
user's signing certificate, access to a DVCS service and 
validation of the DVC is sufficient to verify a signature. Note 
that the DVC does not tell when the signature had been created, 
it only indicates when the signing certificate was valid. 


C.2) A public key certificate for key exchange can be used after 


having obtained a data validation certification certificate to 
encrypt data. The DVC can be stored with the data and/or stored 
by the creator of the encrypted document. 


If an intended recipient of the document claims that the creator 
did not use an appropriate encryption key, the DVC (obtained by 
a recipient’s DVCS) can be used as evidence that the recipient’s 
DVCS has authorized the usage of the public key. 


C.3) The procedure described in the previous paragraph can be 


Adams, 


enhanced to provide domain encryption in several ways. 
Organizations require that encrypted documents need to be 
recoverable. One simple way is to always encrypt documents with 
additional recipients that act as 'domain encryption centers’ or 
"recovery centers’. This is not a technically difficult 
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problem, but may require complicated and difficult interactions 
with the end user, in particular when the document's recipients 
are in several different organizations. 


One possible solution consists of adding additional certificates 
to the dvc that validates the usage of a particular public key 
certificate used for encryption. In an environment of several 
organizations, one of the possible procedures may be: 


The client asks its local dvcs to validate the public key 
certificate. The dvcs forwards the request to a dvcs of a 
remote organization. The remotes organization's dvcs verifies 
the certificate and provides a dvc assertion validating the 
certificate. It adds additional certificates usable for key 
exchange to the certEtcChain structure indicating additional 
required recipients. The local dvc creates a dvc containing the 
dvc of the remote dvcs. It may add additional certificates or 
references to the dvc. The clients use all validated 
certificates to be usable for key exchange to enhance its list 
of recipients. 


In the local dvcs may as well use local information about the 
remote organization’s need for additional recipients. 


Appendix D — MIME Registration 


To: ietf-types@iana.org Subject: Registration of MIME media type 
application/timestamp 


MIME media type name: application 

MIME subtype name: dvcs 

Required parameters: None 

Optional parameters: None 

Encoding considerations: binary or Base64 

Security considerations: Carries a request for a data validation and 
certification service and the response. A request may be 
cryptographically signed. The response will be cryptographically 
signed. 


Interoperability considerations: None 


Published specification: 
RFC 3029 on Data Validation and Certification Server Protocols 
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Applications which use this media type: Data Validation and 
Certification Servers and Clients 


Additional information: 


Magic number(s): None 
File extension(s): .dvc 
Macintosh File Type Code(s): none 


Person & email address to contact for further information: Peter 
Sylvester <peter.sylvester@edelweb.fr> 


Intended usage: COMMON 


Author/Change controller: Peter Sylvester 
<peter.sylvester@edelweb.fr> 


Appendix E — ASN.1 Module using 1988 Syntax 


PKIXDVCS {iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs (15) } 


DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 
—- EXPORTS ALL -- 


IMPORTS 
Extensions, AlgorithmIdentifier 
FROM PKIXIExplicit88 {iso(1) identified-organization (3) 
dod(6) internet (1) security(5) mechanisms(5) pkix(7) 
id-mod(0) id-pkixl-explicit-88(1)) 


GeneralName, PolicyInformation 

FROM PKIX1Implicit88 {iso(1) identified-organization (3) 
dod(6) internet (1) security(5) mechanisms (5) pkix(7) 
id-mod(0) id-pkixl-implicit-88(2)) 


PKIStatusInfo, PKIStatusField FROM PKIXCMP (iso(1) 
identified-organization(3) dod(6) internet (1) security(5) 
mechanisms (5) pkix(7) id-mod(0) 

id-mod-cmp (9) ) 


ContentInfo FROM CryptographicMessageSyntax (iso(1) 
member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-9(9) 
smime (16) modules(0) cms(1)) 
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ESSCertID FROM ExtendedSecurityServices 
( iso(1) member-body(2) us(840) rsadsi (113549) 
pkcs(1) pkes-9(9) smime(16) modules(0) ess(2) } 


CertId, OCSPResponse, CertStatus 

FROM OCSP 

(iso(1) identified-organization (3) 

dod(6) internet (1) security(5) mechanisms(5) pkix(7) id-mod(0) 
id-mod-ocsp(14)) 


SMIMECapabilities FROM SecureMimeMessageV3 
( iso(1) member-body (2) us(840) rsadsi (113549) 
pkcs (1) pkes-9(9) smime(16) modules (0) smime (4) ) 


; 
-- Authority Information Access for DVCS 


id-ad-dvcs OBJECT IDENTIFIER ::- (id-pkix id-ad(48) 4) 


-- Key Purpose for DVCS 


id-kp-dvcs OBJECT IDENTIFIER ::= (id-pkix id-kp(3) 10) 
-- eContentType for a dvcs requests and responses 


id-ct-DVCSRequestData OBJECT IDENTIFIER 
id-ct-DVCSResponseData OBJECT IDENTIFIER 


{ id-smime ct(1) 7 
( id-smime ct(1) 8 


} 
} 


-- Data validation certificate attribute 


id-aa-dvcs-dvc OBJECT IDENTIFIER ::= ( id-smime aa(2) 29 } 


-- using the following bases 


id-pkix OBJECT IDENTIFIER ::- (iso(1) 
identified-organization(3) dod(6) 
internet (1) security(5) mechanisms (5) pkix(7)) 


id-smime OBJECT IDENTIFIER ::= ( iso(l) member-body (2) 
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) 16 ) 


Version ::= Integer 

DigestInfo ::= SEQUENCE ( 
digestAlgorithm DigestAlgorithmidentifier, 
digest Digest 
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Digest ::= OCTET STRING 


Nonce ::= Integer 
DVCSTime ::= 
genTime 
timeStampToken 


CHOICE 1 


) 

TargetEtcChain ::= 
target 
chain 


SEQUENCE ( 


pathProcInput 
} 


PathProcInput ::= SEQUENCE { 
acceptablePolicySet 


inhibitPolicyMapping 
explicitPolicyReqd 
} 


CertEtcToken ::= 
certificate 
esscertid 
pkistatus 
assertion 
crl 
ocspcertstatus 
oscpcertid 
oscpresponse 
capabilities 
extension 


CHOICE ( 


} 


DVCSRequestInformation ::= 


Protocols February 
GeneralizedTime, 

ContentInfo 

CertEtcToken, 

SEQUENCE SIZE (1..MAX) OF 


CertEtcToken OPTIONAL, 
[0] PathProcInput OPTIONAL 


SEQUENCE SIZE (1..MAX) OF 
PolicyInformation, 
BOOLEAN DEFAULT FALSE, 


BOOLEAN DEFAULT FALSE 


[0] IMPLICIT Certificate , 
[1] ESSCertId , 
[2] IMPLICIT PKIStatusInfo , 
[3] ContentInfo , 
I 
T 
I 
I 


[4] IMPLICIT CertificateList, 


[5] MPLICIT CertStatus, 
[6] IMPLICIT Certld , 

[7] MPLICIT OCSPResponse, 
[8] SMIMECapabilities, 
Extension 


SEQUENCE { 


2001 


version INTEGER DEFAULT 1 , 
service ServiceType, 
nonce Nonce OPTIONAL, 
requestTime DVCSTime OPTIONAL, 
requester [0] GeneralNames OPTIONAL, 
requestPolicy [1] PolicyInformation OPTIONAL, 
dvcs [2] GeneralNames OPTIONAL, 
dataLocations [3] GeneralNames OPTIONAL, 
extensions [4] IMPLICIT Extensions OPTIONAL 
) 
ServiceType ::= ENUMERATED ( cpd(1), vsd(2), cpkc(3), ccpd(4) ) 
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DVCSRequest ::= SEQUENCE f 
requestInformation DVCSRequestInformation, 
data Data, 


transactionIdentifier 


GeneralName OPTIONAL 


Data ::= CHOICE ( 
message OCTET STRING , 
messagelmprint DigestInfo, 
certs SEQUENCE SIZE (1..MAX) OF 
TargetEtcChain 
} 
DVCSResponse ::= CHOICE 
{ 
dvCertInfo DVCSCertInfo , 
dvErrorNote [0] DVCSErrorNotice 
) 
DVCSCertInfo::- SEQUENCE { 
version Integer DEFAULT 1 , 
dvReqInfo DVCSRequestInformation, 
messagelmprint DigestInfo, 
serialNumber Integer, 
responseTime DVCSTime, 
dvStatus [0] PKIStatusInfo OPTIONAL, 
policy [1] PolicyInformation OPTIONAL, 
reqSignature [2] SignerInfos OPTIONAL, 
certs [3] SEQUENCE SIZE (1..MAX) OF 
TargetEtcChain OPTIONAL, 
extensions Extensions OPTIONAL 
} 
DVCSErrorNotice ::= SEQUENCE { 


transactionStatus 
transactionIdentifier 


END 


Appendix F - Examples 


PKIStatusInfo , 
GeneralName OPTIONAL 


Adams, 


This chapter contains an example of a request and a response of a 
'Certify Claim of Possession of Data' transaction of the Clepsydre 
Demonstration Project sponsored by La Poste, France. 


The information has been formatted with a slightly modified version 
of Peter Gutmann's dumpasnl program. 
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The response Data Validation Certificate contains the signing 


certificate. 


The data that are time stamped is the binary of the client program 


used to make the request. 


Request: 
0 30 582: SEQUENCE { 
4 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 
: (PKCS #7) 
15 A0 567 [0] ( 
19 30 563 SEQUENCE { 
23 02 l: INTEGER 3 
26 31 Tils SET { 
28 30 9: SEQUENCE { 
30 06 ors OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
37 05 0: NULL 
: ) 
2H 
39: 30: 153 SEQUENCE ( 
42 06 11 OBJECT IDENTIFIER 
id-ct-DVCSRequestData (1 2 840 113549 1 9 16 1 7) 
(S/MIME Content Types (1 2 840 113549 1 9 16 1)) 
55 A0 137 [0] 4 
58 04 134 OCTET STRING, encapsulates ( 
61 30 131: SEQUENCE { 
64 30 96: SEQUENCE ( 
66 0A ls ENUMERATED CCPD (4) 
69 A0 ques [0] 4 
71 A4 45$ [4] ( 
73 30 73: SEQUENCE ( 
25-31 bis SET ( 
77 30 Q: SEQUENCE { 
79 06 3: OBJECT IDENTIFIER 
E countryName (25 4 6) 
: (X.520 id-at (2 5 4)) 
84 13 2% PrintableString 'FR' 
. P } 
l ) 
88 31 14: SET ( 
90 30 12: SEQUENCE { 
92 06 3: OBJECT IDENTIFIER 
: localityName (2 5 4 7) 
: (X.520 id-at (2 5 4)) 
97 13 5$ PrintableString 'Paris' 
. 3 } 
} 
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104 31 16/5. AOR ao SEE A 
106 30 14: . . . . . . SEQUENCE { 


108 06 3: . . . . . . . OBJECT IDENTIFIER 
: organizationName (2 5 4 10) 
(X.520 id-at (2 5 4)) 


TI3-i3 T: 0. . . . . . . PrintableString 'EdelWeb” 
< : ) 
$5 ÁS GI TT } 

122-31 24e TS. eue A So S SEE 

124 30 22: . . . . . . SEQUENCE ( 


126 06 3: . . . . . . . OBJECT IDENTIFIER 
E commonName (2 5 4 3) 
(X.520 id-at (2 5 4)) 


131 13 15: . . . . . . . PrintableString 'Peter Sylvester’ 
e » ) 
} 
- ) 
} 
Bor ee de, Oe le iH 
148 Al LR te em ur e S IE 
150 06 LOS 28 &. 2 OBJECT “IDENTIFIER. “1-3 61 4 I 5309 1 2517 
" L ) 
as To ei] 
162 30 31: . . . . SEQUENCE { 
164 30 Tr. . . . | SEQUENCE { 
166 06 5: . . . . . OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
E (OIW) 
E NE uus ce uer) 
173 04 20: . . . . OCTET STRING 


75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F 
CD 1F A5 66 
) 


) 
Ps $ 
195 31 387: . SET ( 


199 30 383: . . SEQUENCE ( 

203 02 A es INTEGER 1 

206 30 124: . . SEQUENCE ( 

208 30 112: . . . SEQUENCE ( 

210 31 Tl: $ x SEL f 

212 30 9: . . . . SEQUENCE { 

214 06 3: . . . . OBJECT IDENTIFIER countryName (2 5 4 6) 
ee ep (X.520 id-at (2 5 4)) 

219. 13 2: . . . . PrintableString 'FR' 


} 
} 
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223 
225 
227 
232 
246 


248 
250 


255 


288 
290 
292 


297 


322 


332 


334 


341 


343 


345 
347 


358 


360 


373 


375 


386 
388 


31 
30 
06 
13 
31 


30 
06 


13 


31 
30 
06 


13 


02 


30 


06 


05 


AO 


30 
06 


31 


06 


30 


06 


31 
17 


Adams, 


40: 
38: 


Sis 


30: 


2 


to 


13: 
11% 


155 
13: 
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SET ( 
SEQUENCE { 
OBJECT IDENTIFIER organizationName (2 5 4 10) 
(X.520 id-at (2 5 4)) 
PrintableString ’EdelWeb S.A.’ 
} 
ec 
SET ( 
SEQUENCE ( 
OBJECT IDENTIFIER 
organizationalUnitName (2 5 4 11) 
(X.520 id-at (2 5 4)) 
PrintableString 'Clepsvdre Demonstration Service' 
) 
x 
SET ( 
SEQUENCE { 
OBJECT IDENTIFIER commonName (2 5 4 3) 
(X.520 id-at (2 5 4)) 
PrintableString 'Time Stamping Authority’ 
} 
} 


} 
INTEGER 

00 94 88 17 21 34 37 76 
} 


SEQUENCE { 


OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
(OIW) 

NULL 

} 


[01 { 


SEQUENCE { 

OBJECT IDENTIFIER 

contentType (1 2 840 113549 1 9 3) 

(PKCS #9 (1 2 840 113549 1 9)) 

SET { 
OBJECT IDENTIFIER 

id-ct-dvcsrequest (1 2 840 113549 1 9 16 1 7) 
(S/MIME Content Types (1 2 840 113549 1 9 16 1)) 
) 


} 
SEQUENCE { 
OBJECT IDENTIFIER 
signingTime (1 2 840 113549 1 9 5) 
(PKCS #9 (1 2 840 113549 1 9)) 
SET { 
UTCTime '0004171714572' 
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: } 
403 30 35: 


- . . SEQUENCE { 
405 06 9: . . . OBJECT IDENTIFIER 
: messageDigest (12 840 113549 1 9 4) 
HE: (PKCS 49 (12 840 113549 1 9)) 
416 31 22594 xS OA 
418 04 20: . . . . OCTET STRING 
: AD A8 C2 D2 CE 7C OD 04 41 2F 44 13 33 75 DB 2F 
5B 2D F9 DC 
E 
} 
$ 68, x 
440 30 13: . . SEQUENCE { 
442 06 9: . . . OBJECT IDENTIFIER 
G rsaEncryption (1 2 840 113549 1 1 1) 
fon. 4 (PKCS #1) 
453 05 Of- aie ae NULL 
35 creas g) 
455 04 128: . . OCTET STRING 
l 6E 7B OE 36 F5 08 5F 16 3C 31 7B 28 BB OB C2 C6 
17 67 A6 B5 54 F1 98 E2 6F 89 96 OE OC 99 E6 CB 
40 C1 9B 8D D8 D7 8E D3 2B 41 F7 16 26 5B B7 08 
BF E6 95 B2 D9 01 6C FE B1 2C 52 C1 5A D2 31 F3 


8E CA DD 11 A1 72 05 29 41 6A DD 28 40 AA 5C 77 
C6 9D 1D 80 53 DB 6F 9C 4C A5 A3 8F 92 8B 18 3F 
D5 3A AD 01 87 69 C3 FD D3 D8 C3 DO CA 6B E6 OD 
4E 53 6E 50 20 99 7C 94 C2 44 25 1B 06 CO 99 96 


The corresponding data in PEM format are: 


MIICRgYJKoZIhvcNAQCCOIICNzCCAjMCAQMXxCZAJBgUrDgMCGgUAMIGZBgsqhkiG 
9wOBCRABBO6CBiQSBhjCBgzBgCgEEOE2kSzBJMOswCQYDVOOGEWwJGU j EOMAWGA1UE 
BxMFUGFyaXMXxEDAOBgNVBAOTBOVkZWxXZWIXxGDAWBgNVBAMTD1IBldGVyIFN5DbHZI 
c3R1cgEMBgorBgEEAak 9AQIBMB8wBwYFKw4DAhoEFHW2ha9viUZ96ACVIJR5F14/N 
H6VmMYIBgzCCAX8CAQEwfDBwMOSwCOYDVOOGEWwWJGUjEVMBMGA1UEChMMRWRlbFdl 
YiBTLkEuMSgwJgYDVQOLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNl 
MSAwHgYDVQODExdUaW1lIFNOYW1waW5nlIEFldGhvcmlOeQIIAJSIFyEONG3YwCQYF 
KwA4DAhoFAKBfMBOGCSqGSIDb3DOEJAzENBgsqhkiG9wOBCRABBzAcBgkqhkiG9wOB 
CQUxDxcNMDAwNDE3MTCXNDU3WjAjBgkqhkiG9wOBCOOxFgQUTajC0s58DORBLOQT 
M3XbL1st+dwwDQYJKoZIhvcNAQEBBOAEgYBuew4290hfF jwxeyi7C8LGF2emtVTx 
mOJviZYODJnmyODBm43Y147TKOH3FiZbtwi/5pWy2QFs/rEsUsFa0jHzjsrdEaFy 
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BS1Bat0o0Kpcd8adHYBT22+cTKWjj5KLGD/VOq0Bh2nD/dPYw9IDKa+YNT1NUUCCZ 


fJTCRCUDbBsCZlg-- 
ute END PKCS7-- 


Response: 


0 30 2039: SEQUENCE { 


4 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 
(PKCS #7) 
15 A0 2024: [01 { 
19 30 2020: SEQUENCE { 
23 02 Ls INTEGER 3 
26 31 11: SET { 
28 30 9: SEQUENCE ( 
30 06 5: OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
E (OIW) 
37 05 0: NULL 
) 
E . ) 
39 30 301: SEQUENCE ( 
43 06 ld-: OBJECT IDENTIFIER 
: id-ct-DVCSResponseData (12 840 113549 19 16 1 8) 
(S/MIME Content Types (1 2 840 113549 1 9 16 1)) 
56 A0 284 [0] ( 
60 04 280 OCTET STRING, encapsulates ( 
64 30 276 SEQUENCE ( 
68 30 214 SEQUENCE ( 
71 OA 1 ENUMERATED CCPD (4) 
74 AQ 77 [01 { 
76 A4 KEZ [4] 4 
78 30 73 SEQUENCE { 
80 31 11 SET { 
82 30 9 SEQUENCE ( 
84 06 3 OBJECT IDENTIFIER 
countryName (2 5 4 6) 
: (X.520 id-at (2 5 4)) 
89 13 2: PrintableString 'FR' 
š t ) 
: ) 
93: 31 14: SET { 
95 30 125 SEQUENCE ( 
97 06 Se OBJECT IDENTIFIER 
: localityName (2 5 4 7) 
: (X.520 id-at (2 5 4)) 
T0213 5: PrintableString 'Paris' 
v 
: ) 
109 31 16: SET ( 
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111 30 LAS. ge 7B oo SEQUENCE: 
113 06 3: . . . . . . . OBJECT IDENTIFIER 
: organizationName (2 5 4 10) 
(X.520 id-at (2 5 4)) 


118.13 T: 0. . . . . . . PrintableString 'EdelWeb” 
š L ) 
fo-ux e “Gor "uk is } 

127: 3. VA p MIN da uf cor SESE af 

129 30 22: . . . . . . SEQUENCE { 


131 06 3: . . . . . . . OBJECT IDENTIFIER 
: commonName (2 5 4 3) 
(X.520 id-at (2 5 4)) 


136 13 15: .. . . . . PrintableString 'Peter Sylvester’ 
a l ) 
} 
c) 
} 
a ad, E 
153 Al ED Boats. ut œ E 4 
155 06 10: . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1’ 
a 194). 
Tog A2. IDEO mee de EET 
169 A4- 1149. 2 o L4] d 
171 30 112: . . . . . SEQUENCE { 
ETI 3L TUE a e SETA 
175 30 9: . . . . . . SEQUENCE ( 


TG 06 3- Que CL bo ae 4S OBJECT JIDENTIETER 
: countryName (25 4 6) 
(X.520 id-at (2 5 4)) 


182 3 2354555 GL av i crintabrtestring “AER! 
s : ) 
E L) 

186 31 2E a ASA 

188 30 19: . . . . . . SEQUENCE { 


190 06 3: . . . . . . . OBJECT IDENTIFIER 
: organizationName (2 5 4 10) 
(X.520 id-at (2 5 4)) 


195" 13 12: . . . . . . . PrintableString 'EdelWeb S.A." 
7 < ) 
TS ta dal vui NN } 

209 31 AO d 5 ocn LO. ASE d 

211 30 38H. & 9 gx. JOĦQUENCE; 4 


213 06 Bios & a c.v. OBJECT IDENIIEIER 
: organizationalUnitName (2 5 4 11) 
Se seit “dn ERRA (X.520 id-at (2 5 4)) 

218 13 31: . . . . . PrintableString 'Clepsydre Demonstration Service’ 
A E } 

} 
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251 31 laa S74 qo SETS Y 
253 30 30: . . . . . . SEQUENCE { 


255 06 3: . . . . . . . OBJECT IDENTIFIER 
E commonName (2 5 4 3) 
(X.520 id-at (2 5 4)) 


260 13 23: . . . . . . . PrintableString 'Time Stamping Authority’ 
« : ) 
} 
sz 
} 
sx 
Se tion up 
285 30 31: . . . . SEQUENCE ( 
287 30 MES Is. SEQUENCE ( 
289 06 5: . . . . . OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
iem ch BE al 
296 04 20: . . . . OCTET STRING 


75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F 
CD 1F A5 66 
) 


318 02 7: . . . . INTEGER 
$a fy 01 78 OA 1E CA 88 23 
327 18 15: . . . . GeneralizedTime '20000417171617Z' 
. 5 } 
. } 
} 
Ferg e 3 
344 AO 992: . [0] { 
348 30 988: . . SEQUENCE { 
352 30 708: . . SEQUENCE { 
356 AO Su Lk, dm Se. T. af 
358 02 IB Z at 29 INTEGER 2 
fu? sd } 
361 02 8: . . . INTEGER 
$4 s 00 94 88 17 17 64 37 32 
371 30 13: . . . SEQUENCE { 
373 06 v lup Ru g OBJECT IDENTIFIER 
$ . md5withRSAEncryption (1 2 840 113549 1 1 4) 
E (PKCS #1) 
384 05 0: . . . NULL 
a 2. 8s } 
386 30 112: . . . SEQUENCE { 
388 31 Qd e a SET 
390 30 9: . . . . SEQUENCE { 
392 06 3: . . . . OBJECT IDENTIFIER countryName (25 4 6) 
NN (X.520 id-at (2 5 4)) 
397,15 2: . . . . PrintableString 'FR' 


} 
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i ses o a 
401 31 2l: .2. gm Se SET ( 


403 30 19: . . . . SEQUENCE ( 

405 06 3: . . . . OBJECT IDENTIFIER organizationName (2 5 4 10) 
$ ogee i (X.520 id-at (2 5 4)) 

410 13 12: . . . . PrintableString 'EdelWeb S.A.’ 
: } 
oe dee thn H 

424 31 20$... Gs SET ( 

426 30 38: . . . . SEQUENCE { 


428 06 CE D OBJECT IDENTIFIER 
Z organizationalUnitName (2 5 4 11) 
(X.520 id-at (2 5 4)) 


433 13 31: . . . . PrintableString 'Clepsydre Demonstration Service’ 
: ) 
es du 

466 31 32 e SET 

468 30 30: . . . . SEQUENCE { 

470 06 3: . . . . OBJECT IDENTIFIER commonName (2 5 4 3) 
ES (X.520 id-at (2 5 4)) 

4:12: 13 23: . . . . PrintableString 'Time Stamping Authority’ 
: } 

s 

AP ye “ee } 

500 30 30: . . . SEQUENCE { 

502 17 13: . . . UTCTime *000125161938Z' 

514 37 13: . . . UTCTime '2001201619382' 
ET iS. } 

532 30 112: . . . SEQUENCE { 

534 31 BI he tk. si CeBIT 

536 30 9: . . . . SEQUENCE { 

538 06 3: . . . . OBJECT IDENTIFIER countryName (2 5 4 6) 
fax 2 Ta (X.520 id-at (2 5 4)) 

543 13 2: . . . . PrintableString 'FR' 
: ) 
S T T PR 

547 31 E 5 SET A 

549 30 19: . . . . SEQUENCE { 

551 06 3: . . . . OBJECT IDENTIFIER organizationName (2 5 4 10) 
PD Arx (X.520 id-at (2 5 4)) 

556 13 12: . . . . PrintableString 'EdelWeb S.A.’ 
: ) 
a WE 

570 31 40: . . . SET { 

572 30 38: . . . . SEQUENCE { 


574 06 Gu ie. de 4 OBJECT IDENTIFIER 
H organizationalUnitName (2 5 4 11) 
(X.520 id-at (2 5 4)) 
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579 13 31: . . . . PrintableString 'Clepsydre Demonstration Service’ 
: } 
PCS ta dal cv 
612 3T 323.430.5.1 SET 
614 30 30: . . . . SEQUENCE ( 
616 06 3: . . . . OBJECT IDENTIFIER commonName (2 5 4 3) 
Se wa Kee (X.520 id-at (2 5 4)) 
621 13 23: . . . . PrintableString 'Time Stamping Authority’ 
: ) 
x4 
$5 35.6 $ } 
646 30 290: . . . SEQUENCE { 
650 30 13: . . . SEQUENCE { 
652 06 9: . . . . OBJECT IDENTIFIER 
: rsaEncryption (12 840 113549 1 1 1) 
$t esent us (PKCS +1) 
663 05 O: s vow NULL 
PED A: 
665 03 271: . . . BIT STRING 0 unused bits 


30 82 010A 02 82 01 01 00 FA C3 17 AE EB B7 9D 
EB AB BD 05 7E 39 43 6D 04 45 58 74 05 A5 CC F3 
6C 2F 8C 8E 77 7E C2 9F 12 11 5C 7D DB BE 23 28 
9A 90 D2 AB C6 A2 BA BD A3 7E 99 A6 99 21 A5 D8 
90 B9 CF A7 23 4E AO 56 AO C1 OA 46 89 8E 3C 91 
67 37 FD 9B AB 49 17 FC 4A A5 F2 E4 4C 6E E3 6A 
1C 92 97 04 6F 7F OC 5C FB 74 CB 95 7E 4C C3 58 
12 E8 A9 D6 FO DD 12 44 15 E7 8B 2E AF 51 CO OC 
[ Another 142 bytes skipped ] 


So us OG ug } 
940 A3 122: . . . [3] { 


942 30 120: . . . SEQUENCE { 
944 30 15: . . . . SEQUENCE { 


946 06 3: . . . . OBJECT IDENTIFIER basicConstraints (2 5 29 19) 
: (X.509 id-ce (2 5 29)) 


951 04 Gum e OCTET STRING, encapsulates ( 
953 30 6: . . . . . SEQUENCE { 
955 01 Ls BOOLEAN TRUE 
958 02 1 INTEGER 0 
4 
. } 
FOR ako } 
961 30 22: . . . . SEQUENCE { 
963 06 3: . . . . OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 
fu isa Korg (X.509 id-ce (2 5 29)) 
968 01 ME, Ad iss BOOLEAN TRUE 
971 04 12: . . . . OCTET STRING, encapsulates { 
973 30 10: . . . . . SEQUENCE ( 
975 06 8: . . . . . . OBJECT IDENTIFIER ’1 36155 73 10" 
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2 
. ) 

EID ur c } 

985 30 77: . . . . SEQUENCE { 

987 06 SS ow xu OBJECT IDENTIFIER 
: authorityInfoAccess (13 615 571 1) 
I x3 e d (PKIX private extension) 

997 01 Jus" anode iss BOOLEAN TRUE 


1000 04 62: . . . . OCTET STRING, encapsulates { 

1002 30 GOS rise EST SEQUENCE ( 

1004 30 58: . . . . . . SEQUENCE { 

1006 06 BG enu fib esee OBJECT IDENTIFIER '13 615 57 48 4' 


1016 86 AC eo aR Raga Tp] 
l 'https://clepsydre.edelweb.fr/dvcs/service-ccpd' 


1064 30 13: . . SEQUENCE { 


1066 06 9: . . . OBJECT IDENTIFIER 
; md5withRSAEncryption (1 2 840 113549 1 1 4) 
Sa (PKCS #1) 

1077 05 Os ss NULG 
irkotta tila will 

1079 03 257: . . BIT STRING 0 unused bits 


08 DA AF 5B 09 39 66 D3 BE 80 1D D7 72 B5 2C A3 
04 FB 46 F8 05 F5 BF 83 F3 6D 6D 32 28 IC 46 EE 
OF EA 30 61 8A 1E 8A 03 4E 98 81 60 1F 97 17 53 
D1 54 73 3F 72 98 45 D3 10 9A D3 77 B8 74 OE 9A 
90 29 8E AC A4 EB D2 24 6D F6 21 1D 3F 52 8B 2C 
E6 92 E7 52 C6 54 93 91 BC 57 74 21 38 39 75 CD 
30 49 54 13 94 6C FE F1 64 38 1F 5F 7D BB EO 3E 
A8 F1 28 1C F1 D9 28 FA 32 1E 3B 48 BF 5C 70 21 
[ Another 128 bytes skipped ] 


} 
$e a 
1340 31 699: . SET { 


1344 30 695: . . SEQUENCE ( 
1348 02 1: . . INTEGER 1 
1351 30 124: . . SEQUENCE { 
1353 30 112: . . . SEQUENCE ( 
1355-34 Jp. CSET- A 

1357 30 9: . . . . SEQUENCE ( 


1359 06 3: . . . . OBJECT IDENTIFIER countryName (2 5 4 6) 
i (X.520 id-at (2 5 4)) 
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1364 13 2: . . . . PrintableString 'FR' 
: ) 
Sd N 73) 

1368 31 21i 3 ac SETA 

1370 30 19: . . . . SEQUENCE { 

1372 06 3: . . . . OBJECT IDENTIFIER organizationName (2 5 4 10) 
Se wa Kee (X.520 id-at (2 5 4)) 

l3 dg 12: . . . . PrintableString 'EdelWeb S.A.’ 
: ) 
€ dk s ou «5 

1391 31 40% . e 0. SET 4 

1393 30 38: . . . . SEQUENCE ( 


1395 06 Bis any. ue C OBJECT IDENTIFIER 
: organizationalUnitName (2.5 4 11) 
(X.520 id-at (2 5 4)) 


1400 13 31: . . . . PrintableString 'Clepsydre Demonstration Service” 
: ) 
Se urb. cut “ee s 

1433 31 323543, :5 e SETA 

1435 30 30: . . . . SEQUENCE ( 

1437 06 3: . . . . OBJECT IDENTIFIER commonName (2 5 4 3) 
fou ES (X.520 id-at (2 5 4)) 

1442 13 23: . . . . PrintableString 'Time Stamping Authority’ 
: } 

=. 3 

S 81 vp 

1467 02 8: . . . INTEGER 


00 94 88 25 72 35 27 50 
TE ER 
1477 30 9: . . SEQUENCE ( 


1479 06 5: . . . OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
PE: (OIW) 

1486 05 Qf x o NULL 
BS os ol 

1488 AO 276: . . [0] 4 

1492 30 26: . . . SEQUENCE { 


1494 06 Oe p Fo s OBJECT IDENTIFIER 
E contentType (12 840 113549 1 9 3) 
AE" (PKCS 49 (12 840 113549 1 9)) 
1505 31 LETS ba SEL 
1507 06 11: . . . . OBJECT IDENTIFIER 
: id-ct-dvcsresponse (12 840 113549 19 16 1 8) 
(S/MIME Content Types (1 2 840 113549 1 9 16 1)) 
) 


bia ee Ea 
1520 30 28: . . . SEQUENCE { 
1522 06 9: . . . OBJECT IDENTIFIER 

i signingTime (1 2 840 113549 1 9 5) 
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i oes (PKCS #9 (1 2 840 113549 1 9)) 
1533 31 LSS 4 o ^ SET of 


1535 17 13: . . . . UTCTime ’0004171716192’ 
$ i ) 
CE } 

1550 30 35: . . . SEQUENCE { 


1552 06 Oif na Kore OBJECT IDENTIFIER 
E messageDigest (1 2 840 113549 1 9 4) 
sweden Rs (PKCS #9 (1 2 840 113549 1 9)) 
1563 31 229 uu SET 
1565 04 20: . . . . OCTET STRING 
E 68 50 DC 90 20 2E C2 FO 55 15 7F 77 A9 A6 OC 34 
CC 13 06 FA 
za 
ops } 
1587 30 178: . . . SEQUENCE { 
1590 06 IBS ata- f OBJECT IDENTIFIER 
: id-aa-signingCertificate (1 2 840 113549 1 9 16 2 12) 
ile (S/MIME Authenticated Attributes (1 2 840 113549 1 9 16 2)) 
1603-31 (62:3... SETA 


1606 30 159: . . . . SEQUENCE { 
1609 30 156: . . . . SEQUENCE ( 
1612 30 153: . . . . . SEQUENCE ( 


1615 04 20: . . . . . OCTET STRING 
: 5C F1 18 F3 4A CA BA 67 D6 D8 E7 F8 3B 4A D9 7A 
lo... 32 AS 43 A5 

1637 30 128: . . . . . SEQUENCE ( 


1640 30 116: . . . . . . SEQUENCE { 
1642 A4 114: . . . . . . [4] £ 

1644 30 112: . . . . . . . SEQUENCE { 
1646 31 VEA A soos tob 

1648 30 9: . . . . . . . . SEQUENCE { 


1650 06 Sua uius Ad a) a od? b OBJECT IDENTIFIER 
: countryName (25 4 6) 
(X.520 id-at (2 5 4)) 


1655-13 2 dono uisu cs oa TPrimtablestrinġ ER” 
: } 
Stew. x» db Gini M. Al) 

1659 31 G go xim es € SETE 

1661 30 19: . . . . . . . . SEQUENCE ( 


1663 06 3:4 5o dag wc& d OBJECT IDENTIFIER 
$ organizationName (2 5 4 10) 
(X.520 id-at (2 5 4)) 


1668 13 12: . . . . . . . . PrintableString 'EdelWeb S.A.’ 
: } 
EE ie SM eae der E 

1682 31 FOE ce ma sal ux cux SOEI d 

1684 30 38$ . 4. . . « « . SEQUENCE. { 
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1686 06 31 
1691, 15:31 
1724 31 321 
1726 30 30: 
1728 06 She 
1733 13:233 
1758 02 8: 
1768 30 13* 
1770 06 9: 
1781 05 0: 
1783 04 256: 
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OBJECT IDENTIFIER 
organizationalUnitName (2 5 4 11) 
K e (X.520 id-at (2 5 4)) 
.PrintableString 'Clepsvdre Demonstration Service” 
} 
c) 
SET ( 
SEQUENCE ( 
OBJECT IDENTIFIER 
commonName (2 5 4 3) 
(X.520 id-at (2 5 4)) 
PrintableString 'Time Stamping Authority” 
} 
} 


} 

c. 

} 
INTEGER 

00 94 88 25 72 35 27 50 


SEQUENCE { 


OBJECT IDENTIFIER 

rsaEncryption (1 2 840 113549 1 1 1) 
(PKCS #1) 

NULL 

} 


OCTET STRING 


2E 70 9F 56 5E 01 56 AY El 47 81 12 35 21 29 09 
16 7A ED 45 F9 5A A2 ED E4 FE 9D 2C E4 DA 12 66 
62 14 59 61 8B 50 7B 01 82 3D BD 7E E6 38 DO A8 
AO 37 98 79 13 26 39 29 C6 72 20 A9 95 71 E7 53 
7F 79 77 98 EF 23 02 4E B9 BD 90 9B AC 05 A2 70 
8F 3A 42 36 9C 2C BO 94 B1 2B OB 36 94 OE 78 OE 
BO D1 09 20 63 BC FF CD 32 F1 5A D3 AB 9F 93 9C 
5A A3 58 99 AO 28 11 EO 80 4D 4D 1E 77 04 F4 50 
[ Another 128 bytes skipped ] 
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The corresponding data in PEM format (together with a technical textual 
description) are: 


Data Validation Certificate: 
Request Information: 
Service: Certify Claim of Possession of Data — ccpd(4) 
Policy: EdelWeb Customer Policy Clepsydre 
Requester: 
DirName: /C=FR/L=Paris/O=EdelWeb/CN=Peter Sylvester 
DVCS: 
DirName:/C-FR/O-EdelWeb S.A./ 
OU-Clepsydre Demonstration Service/CN=Time Stamping Authority 
SerialNumber: 01780aleca8823 


MessageDigest: 
Algorithm: shal 
Data : 75B685AF6F89467DE80715251E45978FCD1FA566 


Asserted Time: 
Generalized Time: 17-Apr-2000 19:16:17 (Apr 17 17:16:17 2000 GMT) 
Certificate: 
Data: 
Version: 3 (0x2) 
Serial Number: 
94:88:17:17:64:37:32 
Signature Algorithm: md5WithRSAEncryption 
Issuer: C=FR, O=EdelWeb S.A., 
OU-Clepsydre Demonstration Service, CN=Time Stamping Authority 
Validity 
Not Before: Jan 25 16:19:38 2000 GMT 
Not After : Jan 20 16:19:38 2020 GMT 
Subject: C=FR, O=EdelWeb S.A., 
OU-Clepsvdre Demonstration Service, CN=Time Stamping Authority 
Subject Public Key Info: 
Public Key Algorithm: rsaEncryption 
RSA Public Key: (2048 bit) 

Modulus (2048 bit): 
00:fa:c3:17:ae:eb:b7:9%d:eb:ab:bd:05:7e:39:43: 
6d:04:45:58:74:05:a5:cc:f3:6c:2f:8c:8e:17:7e: 
c2:9f:12:11:5c:7d:db:be:23:28:9a:90:d2:ab:c6: 
a2:ba:bd:a3:7e:99:a6:99:21:a5:d8:90:b9:cf:a7: 
23:4e:a0:56:a0:c1:0a:46:89:8e:3c:91:67:37:fd: 
9%b:ab:49:17:fc:4a:a5:f2:e4:4c:6e:e3:6a:1c:92: 
97:04:6f:7f:0c:5c:fb:74:cb:95:7e:4c:c3:58:12: 
e8:a9:d6:f0:dd:12:44:15:e7:8b:2e:af:51:c0:0c: 
5f:a8:65:fc:47:a1:c9:98:1f:d4:el:ea:bc:1lc:la: 
27:bb:8b:56:f1:12:55:10:f4:8e:d8:9f:19:9c:1le: 
81:f7:db:63:dd:88:37:3f:71:79:5b:96:e2:5f:82: 
d5:12:19:05:0d:e1:3d:a5:6d:66:e4:2c:1e:ed:c7: 
4c:b8:df:aa:38:c8:15:6a:ae:25:7d:46:2a:07:£9: 
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83:77:c4:51:ee:90:dc:05:d0:c3:f0:f1:5f:e8:d4: 
6d:5d:34570:91:9d:9f:08:55:74:5b:65:8d:5f£f:354 
59:83:4e:72:19:5bb:9c:88:d1:7a:£c:23:a5:84:99: 
b4:17:8a:4d:6c:9d:d0:a6:35:80:5f:ca:fb:24:8b: 
54:1d 
Exponent: 65537 (0x10001) 
X509v3 extensions: 
X509v3 Basic Constraints: 
CA:TRUE, pathlen:0 
X509v3 Extended Kev Usage: critical 
DVCS Signing 
Authority Information Access: critical 
DVCS — URI:https://clepsydre.edelweb.fr/dvcs/service-ccpd 


Signature Algorithm: md5WithRSAEncryption 
08:da:af:5b:09:39:66:d3:be:80:1d:d7:72:b5:2c:a3:04:fb: 
46:f8:05:f5:bf:83:f3:6d:6d:32:28:1c:46:ee:0f:ea:30:61: 
8a:1e:8a:03:4e6:98:81:60:1£:97:17:53:d1:54:73:3£:72:98: 
45:d3:10:9a:d3:77:508:74:0e:9a:90:29:8e:ac:a4:eb:d2:24: 
6d:f6:21:1d:3f:52:8b:2c:e6:92:e7:52:Cc6:54:93:91:bc:57: 
74:21:38:39:75:cd:30:49:54:13:94:6c:fe:f1:64:38:1f:5f: 
Td:bb:e0:3e:a8:f1:28:1c:f1:d9:28:fa:32:1le:3b:48:bf:5c: 
70:21:29:ef:be:72:24:da:0d:f9:51:7a:fe:d7:f5:ff:e8:c2: 
ea:c6:4c:45:14:51:53:£d:00:d5:5b:cc:67:2a:23:94:31:9e: 
c2:90:38:9b:b0:df:f9:de:67:0c:57:5c:d7:b0:fc:f2:72:96: 
c4:dl:7a:%d:a0:e6:51:24:99:9e:89:c6:39:f9:72:7a:44:fd: 
2d:3f:bovdfsol:25:27:94:al:b5:7d:ba:06:75:71607$T10:957066: 
Dbd:20:74541:3e:0d26€d:39:50:20:90€:03:023:09:63:279:d5:6b: 
85:e8:£1:72:29:80:£6:c6:6e:61:1b:58:fc:87:3e:d9:e1:53: 
10:e0:b1:05 


== E BEGIN PKCS7----- 

MITH9wYJKoZIhvcNAQcCoIIH6DCCB+QCAQMxC zAUBgUrDgMCGgUAMIIBLOYLKoZI 
hvcNAQkQAQigggEcBI IBGDCCARQwgdYKAQSgTaRLMEkxC zAJBgNVBAYTAkKZSMOQ4w 
DAYDVQQHEWVOY XJpczEQMA4GA1UEChHMHRWRIbFdLY jJEXMBVGALUEAxMPUGVOZXIg 
U3lsdmVzdGVyoQwGCisGAQOBqTOBAgGidKRyMHAxCZAJBgNVBAYTAkZSMRUWEWYD 
VOOKEwXFZGVsV2VilFMuQSA4xKDAmBgNVBASTHONsSZXBzeWRyZSBEZW1vbnNOcmFO 
aW9uIFNlcnZpY2UXxIDAeBgNVBAMTFIRpbWUgU3RhbXBpbmcgOXV0aG9yaXR5MB8w 
BwYFKwADAhoEFHW2ha9viUZ96AcVJR5F14/NH6VmAgcBeAoeyog jGA8yMDAwMDOx 
NzE3MTYxN1qgggPgMIID3DCCAsSgAwIBAgIIAJSIFxdkNzIwDOYJKoZIhvcNAQEE 
BOAwCDELMAkGA1UEBhMCRIIXFTATBgNVBAOTDEVkZWxXZWIgUy5BLjEOMCYGAlUE 
CxMfQ2xlcHN5ZHJlIERIbW9uc3RyYXRpb24gU2VydmljZTEgMBA4GA1UEAxMXVGlt 
ZSBTdGFtcGluZzyBBdXRob3JpdHkwHhcNMDAwMTIIMTYxOTMAWhCNMjAwMTIWMTYx 
OTMAWjBwMOswCQYDVOOGEWwJGUjEVMBMGAl1UEChMMRWRlIbFdlYiBTLkEuMSgwJgYD 
VOOLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNlMSAwHgYDVQODExqdU 
aW11IFNOYW1waW5nIEF1dGhvcml10eTCCASIwDOYJKoZIhvcNAQEBBOADggEPADCC 
AQOoCggEBAPrDF67rt53rq70Ff31DbO0RFWHOFpczzbC+M3jnd+wp8SEVx92743KJq0 
OqvGorqg903 6ZppkhpdiQuctnl06gVqDBCkaJj jyRZ2zf9m6tJF/xKpfLkTG7 jahys 
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lwRvfwxc+3TL1LX5MwlgS6KnW8NOSRBXniy 6vUcAMX6h1/EehyZgf1lOHqvBwaJ7uL 
VvESVRDOJtifGZwegffbY92INzZ9xeVuwW41+C1RIZBO3hPaVtZuQ0sHu3HTL3fqjjl 
FWquJX1GKgf5g3fEUe603AXOw/DxX+3JUTVOOCIJGANWhVf£Vv13]V81WYNOchm7nI3R 
evw]JpYSZtBeKTWyd0KY1gF/K+ySLVBOCAWEAAaN6MHgwDwYDVROTBAgwBgEB/wIB 
ADAWBgNVHSUBAf8EDDAKBggrBgEFBQcCDCjBNBggrBgEFBQCBAQEB/wQ-MDwwOgYI 
KwYBBQUHMASGLmhOdHBzOi8vY2xlcHN5ZHJlLmVkZWx3ZWIuZnIvZHZjcy9zZXJ2 
aWNILWNjeGQwDQX JKoZIhveNAQEEBQADggEBAA jari sJOWbTvoAdI3KILKMEHObA 
BfW/g/NtbTIoHEbuDtowYYoeigNOmIFgH5cXU9FUcz9ymEXTEJrTd7hODpqQKY6s 
pOvSJG32IR0/Uoss5pLnUsZUk5G8V3QhODl1zTBJVBOUbP7xZDgfX3274D608Sgc 
8dko*jIeO0i/XHAhKe-ttciTaDflRev7X9f/owurGTEUUUVPO9ANVbzGcqI5QxnsKQ 
OJuw3/neZwxXXNew/PJylsTRep2g5lEkmZ6Jxjn5cnpE/S0/vN/HJSeUobV9ugZ1 
ZxyVbLOsdEEtzc05XC6cw8MJ43nV64Xo8XIpgPbGbmEbWPyHPtnhUxDgsQUxggK7 
MIICtwIBATB8MHAxCzAJBgNVBAYTAkZSMRUwEwYDVOOKEwxFZGVsV2VilFMuQS4Ax 
KDAmBgNVBASTHONSZXBzeWRyZSBEZW1vbnNOcmFOaW9uIFNlcnZpY2UxIDAeBgNV 
BAMTFiRpbWUgU3RhbXBpbmcgOXVOaG9yaXR5AggAlIglcjUnUDAJBgUrDgMCGgUA 
OIIBFDAaBgkqhkiG9wOBCOMxDQYLKoZIhvcNAQkOAOgwHAYJKOZIhvcNAQkFMO8X 
DTAwMDOxNZzE3MTYxOVowIwYJKoZIhvcNAQkEMRYEFGhQ3JAgLsLwVRV/d6mmDDTM 
Ewb6MIGyBgsqhkiG9wOBCRACDDGBojCBnzCBnDCBmQQUXPEY80rKtGfW2Of4O0rZ 
ejKl1Q6UwgYAwdKRyMHAxCZzAJBgNVBAYTAkZSMRUwWEWYDVOQOKEwxFZGVsV2VilFMu 
QSA4xKDAmBgNVBASTHONSZXBzeWRyZSBEZW1vbnNOcmFOaW9uIFNlcnZpY2UxIDAe 
BgNVBAMTF1IRpbWUgU3RhbXBpbmcgOXV0aG9yaXR5AggAllIglcjUnUDANBgkqhkiG 
9wOBAQEFAASCAQAucJ9WXgFWqeFHgRIl1ISkJFnrtRflaou3k/p0s5NoSZmIUWWGL 
UHsBgj29fuYA40KigN5h5EyY5KcZyIKmVcedTf313mO8jAk65vZCbrAWicl1860jac 
LLCUsSsLNpQOeA6wOQkgY7z/zTLxWtOrn5OcWqNYmaAoEeCATUOedwTOUAfVilSg 
IzL/ppziurjbVUfJyLoH75AUSKi2xXzVqSBOHFbvjxuz/IdtgfHUbxqHMJJHaeB5 
4LwQmc9NNkw2Al1FyOVumHi2G8R8K6L/rOPnOGuywjlGuKjtGhL9NjJ/uH-*/FNaNj 
vjjAA3w6XrjPOxgQiNu7T3j2-ttQcjdT4--tO 

=== END PKCS7----- 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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